home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000693_marca@wintermu….ncsa.uiuc.edu _Fri Feb 26 20:02:39 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA25043; Fri, 26 Feb 93 20:02:39 MET
  4. Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA09849; Fri, 26 Feb 1993 20:19:53 +0100
  6. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18541
  7.   (5.65a/IDA-1.4.2 for WWW-TALK@nxoc01.cern.ch); Fri, 26 Feb 93 13:19:52 -0600
  8. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  9.     for @newton.ncsa.uiuc.edu:WWW-TALK@nxoc01.cern.ch id AA28924; Fri, 26 Feb 93 13:21:38 -0800
  10. Date: Fri, 26 Feb 93 13:21:38 -0800
  11. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  12. Message-Id: <9302262121.AA28924@wintermute.ncsa.uiuc.edu>
  13. To: Kim Peter Nyberg <kny@cs.hut.fi>
  14. Cc: WWW-TALK@nxoc01.cern.ch
  15. Subject: re: xmosaic experience
  16. In-Reply-To: <199302261020.AA22920@cardhu.cs.hut.fi>
  17. References: <199302261020.AA22920@cardhu.cs.hut.fi>
  18.     <9302252239.AA21530@wintermute.ncsa.uiuc.edu>
  19.     <EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
  20. X-Md4-Signature: b92ea52940f158846b4e2c35c183fe16
  21.  
  22. Kim Peter Nyberg writes:
  23. > Marc Andreessen writes:
  24. >  > The X Window System has this (to me, fatally flawed) design decision I
  25. >  > hadn't suspected.  X windows can only be so big.  Up to the size of a
  26. >  > 16-bit integer, in fact, in pixels.  This is really really bad.  This
  27. > 
  28. > Well, unless we'll be seing >32k*32k displays in the near future, it's
  29. > not that bad.
  30.  
  31. It is bad, because X's "virtual" window concept is a very convenient
  32. way of doing things, and because the decision to chop pixel
  33. coordinates to 16 bits is completely arbitrary -- Xlib in fact allows
  34. you to pass in 32 bits, but this gets truncated to 16 bits by the time
  35. the server gets it.  It's just plain silly that it's not 32 bits all
  36. the way through.
  37.  
  38. >  > Mosaic does, which is lay out as much text as possible in the window
  39. >  > and then give you convenient automatic inlined hyperlinks to the
  40. >  > remainder of the text, partitioned into window-sized chunks.  Then
  41. >  > tell me who's making fatally flawed decisions.
  42. > 
  43. > Hmmmh, no offence, but I think that's not not the correct way to
  44. > solve the problem.
  45.  
  46. I agree that ideally we should be doing the scrolling ourselves, but
  47. like I said, that has a number of concomitant effects that we're not
  48. willing to accept right now.
  49.  
  50. > Btw, have the current x-clients implemented non-blocking transfers?
  51. > It should be implemented in the common code, maybe it already is.
  52. > It's really too bad that we don't have the time to support erwise
  53. > (three of us are working almost full time at a software company, and
  54. > try to get on with our studies as well). Maybe in the summer ...
  55.  
  56. I sure would like to have non-blocking I/O... I have looked at the
  57. Erwise code for this, and am thinking about stealing a lot of your
  58. changes, but haven't had time yet......
  59.  
  60. Cheers,
  61. Marc
  62.  
  63. --
  64. Marc Andreessen
  65. Software Development Group
  66. National Center for Supercomputing Applications
  67. marca@ncsa.uiuc.edu
  68.